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Editorial 


Welcome to the first issue of the CUGI newsletter for 1991. The more 
observant of you will have noticed that this should actually have been the 
last issue of 1990. There are a couple of reasons why things have slipped 
back a month. The main one is because very few articles were submitted, 
(In fact, two of the articles included here were actually left over from the 
previous issue due to space considerations.) I waited and waited, hoping 
that there would be a last minute flood. There wasn’t. As a result, this 
issue is noticeably smaller than the previous one. 

On the positive side though, it gives us a good opportunity to change 
over from a March, June, September, December cycle to January, April, 
July, October. This has a few advantages. The December issue always 
ended being a mad rush because of Christmas, and similarly, the June issue 
usually ended up arriving in July anyway because of exams. The September 
issue had the problem that potential article submitters were usually on 
holiday until about a fortnight before the newsletter was produced. Moving 
everything back a month seems to fit in much more smoothly. 

So, what’s inside this slimmed down issue? On the hardware front, Marc 
Whisker takes a look at the Courier HST 9600 bps modem which is currently 
one of the most popular high speed modems available. A year ago, 9600 
bps modems were almost unheard of on the Irish comms scene; now, there 
are five local Dublin BBS’s supporting 9600 bps in one form or another. 
It looks like the days of the 2400 bps modem are numbered. Of course, to 
make the most of these new high speed modems, you need good software. 
Declan McArdle takes us on a guided tour of JR-Comm, one of the most 
popular Amiga comms packages, and just the thing to complement your 
shiny new HST, 

Meanwhile, on the programming front, William Leeson explains how to 
create Intuition screens, while I cover a few handy tricks you can use o 
make your C programs smaller, More and more people seem to be taking 
the plunge into C programming so this trend of articles on C is likely t° 
continue, particularly now that there are now no fewer than three freely 
distributable C compilers available. Finally, for those of you with r 
head in the clouds, Rocco Matassa tells us why Flight Simulator I F! 
and Falcon are his pick of the crop of Amiga flight simulators. 

Apologies to anyone who turned up for a CUGI meeting on January 
dth. As you no doubt discovered, there wasn’t a meeting on that evening: 
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We did announce this at the meeting prior to Christmas but those of you 
who weren't there may have been caught out. We will be sticking with 
the new fortnightly cycle, which means that the next four meetings will be 
on February 8, February 22, March 8 and March 22. Make a note in your 
diaries. 

‘ Things have been fairly quiet over the past few months. One item of 
note is that we (CUGI) have now purchased our own A500. This will be 
useful as a testbed for any hardware projects developed by members, as 
well as allowing us to rely somewhat less on the generosity of St. Andrew’s 
College in allowing us to use their equipment. 


Another notable event has been Commodore UK’s relaunching of the 
A2000 as the A1500, with a bundled second internal drive, hires monitor 
and lots of software — all for about the same price as the original A2000! 
Quite a few members have already taken the plunge (and at the same time 
taken the opportunity to upgrade their 20 Mb A590’s to 180 Mb SCSI 
drives). Doubtless, one of them will be reporting on whether it was worth 
the effort in the next issue. 


Last time, I mentioned that Declan McArdle and a group of Dublin 
Sysops were setting up an organisation to provide access to the global 
Usenet network within Dublin. I’m pleased to report that this service is 
now up and running, under the name DBUG (Dublin Based Usenet Group). 
The system is currently running on top of the TOPPSI bulletin board (ring 
711047, 24 hours/day) although it may eventually migrate to a full Unix 
system. Full news and electronic mail facilities are provided, and a year’s 
subscription will set you back £50. Ring Declan on 884195 for more infor- 
mation. In the meantime, one more way to submit your CUGI articles is 
by mailing them to ecarroll@dbug. hobby .ie. 

Commodore had planned to hold their annual European Amiga Devel- 
oper’s Conference in Milan on February 13-16. However, this has now been 
postponed (presumably because of the Gulf War). Hence, I’ve had to delete 
the paragraph which said I was looking forward to going, and replace it with 
this one which says that I hope it will be rescheduled some time soon. Re- 
member, you heard it first from CUGI! (This news is about + hours old as 
I type this.) All going well, I may have a report for the next newsletter. 

That about covers everything. All that remains is to wish you all a happy 

.and prosperous 1991. 


E.C. 
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US Robotics Courier HST Reviewed 
by Marc Whisker 


What’s happened to the days when 2400 bps was unbelieveably fast? Her, 
I'll try to justify if it’s worth your while porehesug what is probably the 
best communications modem available on the market. Why did I biri 
Well, I really purchased it not for my own benefit, but for the benefit of the 
users of Niteline BBS (which you can call 24 hours a day on 01-834660)! 


I received my modem three weeks after having ordered it from the United 
States. It arrived in a rather large box for your average modem, but then, 
is the Courier HST your average modem? Let’s briefly take a look at it. 


There are three types of Courier modems: the normal HST, the V.39 
version, and the Dual Standard which is a combination of the HST and 
V.32. First, a brief explanation of the differences between V.32 and HST, 
V.32 is 9600 bps full duplex (9600/9600) which means you can transmit and 
receive data at 9600 bps, as proposed by the CCITT in 1984 and approved 
just recently. The HST is slightly different; it operates in a similar way to 
the old split speed of 1200/75 but with one big difference. You connect to 
the remote host at a split speed of 14400/450, i.e. you receive data at 14400 
but only transmit at 450 bps. 


This doesn’t mean that when you upload you must do so at 450 bps, 
however. The HST’s are very intelligent modems. When I want to upload 
a 300K file, I would normally prefer to switch down to 2400 bps rather 
than have to upload at 450 bps (even though I receive data at 14400 bps). 
However, when you do decide to transmit large amounts of data, a line 
reversal takes place. This means that the transmit /receive speeds switch 
around, i.e. I send at 14400 bps, but only receive at 450 bps. This switch is 
automatic and is so instantaneous that you never actually notice the change 
taking place. The overall effect is a psuedo 14400/14400! connection. 

i ae the HST modem is much cheaper to buy than the V.32 model 
i Srei ER ap but V.32 is expected to be the standard eyentun y 
others EE d ae think So, considering the price difference of £200, = 
V38 tidem ¢ ma with me. [Note that while many companies io 
to calling other HS aie! Produce the HST so HST users are constr 

T modems if they use speeds above 2400 bps - Ed] 


N , 
liae mie a look at the modem itself and its various advantages ê? 
ges (if any!). The overall appearance of the HST is very nice. 


It’s a rather long black unit, about an inch and a half thick. The front has 
a display of 12 LED’s hidden behind tinted glass (well, it’s actually plastic). 
This means that you cannot see the LED’s until the modem is switched on. 
On the front of the modem underneath the lip, there is a volume knob to 
adjust the loudness of the speaker, which I think is a great idea. 


There are no actual switches on the front. The rear of the modem is 
very different. There is a whole panel of DIP switches, all of which are 
explained on the base of the modem and in the manual, but outlining them 
here is too detailed for this article. There are two RJ11A sockets, one for 
the incoming telephone line and the other for your telephone. Next, there 
is the power supply socket and last, but by no means least, is the RS232C 
interface plug. The on/off switch is also located at the rear. 

As the American mains voltage is 110V and the European is 220V, don’t 
plug the Courier straight into our mains supply if you get it from the USA! I 
have a step-down transformer into which I plug the modem’s power supply. 
I doubt it’s designed for 24 hours a day use, but mine hasn’t burnt out yet! 
It does get uncomfortably warm to touch however. 


The modem understands standard Hayes commands (for those of you 
who don’t know, the Hayes commands are a standard way of telling a 
modem how to do things like dial a phone number and change settings). 
This means that it will work with just about any communications software. 


Some of the nicer features I like about the HST follow. You can send a 
command to it (ATX7) and it will listen to the line to detect if there is a 
dialtone or not. It will also detect if the remote computer you are calling 
is engaged, and if so, it will return BUSY. You can set your dialling method 
to hunt, meaning it will try to dial the number using DTMF (tone dialling) 
and if this fails, it will switch to the older method of rotary dialling (pulse). 

Other commands include a help screen giving you a list of what each 
command does. You can also store your own defaults in the modem’s non- 
volatile (battery backed) RAM. After a call, you can get a list of the link 
diagnostics which gives you information on how fast the data was trans- 
mitted and the reason for disconnection. The HST also includes a new 
command A> which tells it to continuously repeat the previous command. 
This is useful for dialling a particular phone number over and over again 
until you get through. There is an inbuilt ROM and RAM test, and you 
can store your most often called numbers in its memory. 

Another function the modem includes is that if when you connect at 
14400/450, the data being received is too corrupted, both ends will auto- 
matically carry out a function called Online Fall back/Fall forward. This 
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severe line impairments — the integrity of data transfe 
h ends will fall back to 12000 bps; if necessary, they vil 
o 9600 bps. However, as line improvements oce 
the modems automatically shift up to the next mane speed and so op,’ 

Well, I'll bet you're saying to yourself, how does it know that the data 
is corrupted? It does this using a system called T rellis Coded Modulation 
(TCM) which allows it to detect if what yis received is different to what 
was originally sent by the remote modem. I’m not too clear exactly hoy 
it works, but I know that at speeds above 2400 bps, this technique makes 
high speed data transmission less vulnerable to errors. The modems can 
tolerate twice as much noise in the telephone channel as they could with 
the conventional Quadrature Amplitude Modulation (QAM) which is used 
for 2400 bps. 

Now we come to the question of what is MNP and V42bis. MNP is 
available in various different types ranging from level 1 to 9. If your modem 
has MNP 5, then this means it includes levels 1-4 as well. 

MNP levels 1 to 4 are a method of error control which prevent you 
receiving corrupted data from the remote host. They also send the data in 
a slightly more efficient manner, increasing the speed by about 12%. MNP 5 
is slightly more complex. It compresses the data being sent so that more 
information is transmitted into each second of your call (handy if you're 
calling the UK or USA). If you are receiving pure text, you can get up to 
50% compression but this reduces to almost nothing if you are transferring 
archive files which have already been compressed. 

V42bis is a new method of data compression, only recently released. 1 was 
lucky to have it already programmed into the ROM of my HST. To avoid 
getting technical about V42bis, all it is is a method of data compression 
that supersedes MNP 5 compression, so we get even more information pe! 
second of the call! 

_ Effectively, using the HST at 14400/450 bps with V42bis data compres 
sion, you get approx 1650 characters per second, which is a massive 1" 
provement over the 240 characters per second you get on a 2400 modem: 
Of course, you can only avail of these added features if the remote modet 
You are connected to supports them also, 

: Allin all, the HST is a nice modem to use, if you can afford it. I believe 
mice ee but it is much cheaper to man ai 
Ti formation on the HST. T eran a ot vant sett 0 
leave me a messag are feel free to ask me at any CUGI m 

sage on Niteline, 


means that if 
at 14400 bps, bot 
will fall further back t 


3 January 199! 


p. 


Cutting your code down to size 


by Eddy Carroll 


Cast your mind back to the days of the 3.5K VIC 20. Memory was expensive 
and scarce, and every byte counted when you were programming. It was 
possible to squeeze Pacman and Space Invaders into that 3.5K memory, 
along with countless other programs. 


Nowadays, memory is much cheaper and we think nothing of a program 
taking up 100K, 200K or even 500K (as used by most modern games). 
In spite of this though, I think there is still a certain satisfaction to be 
obtained from knowing that your code is lean and mean, with not an ounce 
of unnecessary fat. So, in this article, I’m going to look at some of the 
ways in which you can reduce the size of your programs. Quite often, these 
techniques will result in code that executes faster as well, not to mention 
taking up less room on your disks. 

I’m going to assume everyone is using SAS/C (formerly Lattice C), since 
it is pretty much the standard on the Amiga. If you're using a different 
compiler, you may still find some of the tips useful. Be warned that quite a 
few of the reduction techniques swap safety for speed. If you get everything 
right, all will be well, but if you make a mistake, you’re much more likely 
to meet the guru than to get a helpful diagnostic message. 


So, where to start? The first thing to do is to make sure that you are 
making full use of the compiler facilities. SAS/C has a large number of 
command line options and many of these help to reduce your code size. 
The most obvious is the -v option. This disables the stack checking code 
that normally gets included at the start of each function. Stack checking is 
handy while you are developing your code but once it is working okay, you 
don’t really need it unless your program uses a lot of stack space. The actual 
checking code that gets added to your code is not all that much (about 4 
bytes per function); the real space waster is the code for the stack overflow 
requester which is pulled in from the library when you link. Leaving this 
out saves about 300 bytes. 

Another useful option is -rr which tells the compiler to pass the pa- 
rameters to each function in CPU registers rather than on the stack. This 

removes the code to push registers onto the stack for the calling subroutine, 
and also the code to pop them off again at the other end. It makes your 
code run a little faster too. The -cs option is also useful; it saves space by 
only storing a single copy of a string if it is used more than once. 


N 
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tell the linker to combine all the code and data part 
rogram into single units rather than lots of little units; this doesn 
ode in memory much but it does make the executable 
d it also loads in faster. (As an extreme example, one 
hese option shrunk from 220K to 210K and it 


The -Le. -Ld options 
of your p 
reduce the size of c 
file a bit smaller an 
program I relinked with t 
loaded three times faster!) 

Another good way to reduce code size is to make use of the appropriate 
header files. If you include stdio.h, SAS/C treats calls to printf() in a 
special way. If the format string doesn’t contain any special formatting 
characters, a tiny version is used. If the format string only contains 4s and 
4d, then a mini version is used. The full blown version is only used if you 
make use of any of the more exotic fomatting options. Since printf() is usu- 


ally quite a big function, using the smaller versions can be well worthwhile, 


Similar benefits can be obtained by including string.h, which causes 
calls to strepy() to be recognised and replaced by inline code. If the ar- 
gument is a constant string, then the call will be replaced directly by the 
length of the string! 

The most useful files to include however are the prototype files for all 
the Amiga library functions, for example proto/exec.h, proto/dos.h and 
proto/intuition.h. They cause SAS/C to generate inline code for any 
calls to functions in the particular library, rather than going via stub rou- 
tines in amiga.1ib. If you call all the Amiga library functions like this, you 
need not link with amiga.1ib, which speeds up the linking process as well. 

So much for the easy savings. To realise more substantial reductions in 
code size, you need to minimize your dependance on library code. A stan- 
dard empty program in SAS/C is about 3K. If you will only be running your 
program from the CLI and it doesn’t take any command line arguments, 
you can strip off about 1K by calling your entry function _main() instead 
of main(). 

If you do this, you won't be able to use the stdio facilities. However 
this is not a loss, since calling the AmigaDOS functions Open), Close(), 
Read(), and Write() directly is much more efficient than calling fopent) j 
felose() etc. You do have to do a little more work though. 
os acaaie g men what other functions are being drags 
which causes eh a as ap is to use the -Ls optie aa 
brought in from th on due ‘ ae file listing all the modules sae i y 
be amazed by ~ ' f ER She im Spe ypu try DITO ie m 
awd Rp i rong in for a simple pros 

rid. The good news is that much of the excess baggage “ 


ed into 
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be removed fairly easily, by simply including equivalently named functions 
in your own code that do nothing. These functions supercede the ones in 
the library and take up much less space. Some suitable functions for this 
treatment are MemCleanup() and chkabort(). 


One final trick you can do is to add DEFINE --main=_-_tinymain to your 
BLINK command line (or WITH file). This removes the stdio code from the 
startup code, but still allows you to access the command line arguments 
and run your program from Workbench. Better yet, that annoying console 
window that pops up on the Workbench screen is no longer present. 


To finish off with, here’s a version of the ECHO command which uses 
some of the tricks above to keep its code down to size. The final executable 
file comes out at around 160 bytes which is pretty tiny, even for assembly 
language. It achieves its small size by bypassing the standard startup code 
completely. This means that certain initialisation functions (like setting 
register A4 to point to the base of global data, and opening dos . library) 
must be carried out by hand. Note also that the command line we receive 
is in raw format and not even guaranteed to be zero-terminated. 


/* Compile with: LC -cq -v ECHO.C 
* Link with: BLINK ECHO.O0 TO ECHO 
*/ 

#include <exec/types.h> 

#include <libraries/dos.h> 

#include <proto/exec.h> 

#include <proto/dos.h> 

#include <dos.h> 


struct DosLibrary *DOSBase; 


__asm int startup(register __a0 char *cmdline, 
register _.dO int len) 
{ 
geta4(); 
DOSBase = (struct DosLibrary *)OpenLibrary("dos.library", 0); 
if (DOSBase) { 
Write(Qutput(), cmdline, len); 
CloseLibrary (DOSBase) ; 
} 
return (0); 


} 
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Discount Corner 


by Geoffrey J. Reeves 


Most members should be aware of the many items which we can help you to 
get at discounted prices. Some of these are available directly from CUGI, 
some by other means. Associate Members can avail of these too although 
postage and packing costs may have to be met by the member(s) concerned, 


Books 
There are many good bookstores. Some us have dealt with MicroMail in 


Cork and have found them very friendly and helpful. They do have a fixed 
£2 delivery charge but that’s for Securicor next day delivery. Despite this, 
their prices seem very competitive and their catalogue is extensive. You 
can ring them on 021-317686. 


Software 

CUGI doesn’t sell software directly, but if you are looking for a particular 
package, we can usually point you in the direction of good prices. Bear in 
mind that with our high VAT rate, combined with the lack of competition 
in the Dublin market, it usually works out much cheaper to mail order 
software from the UK. 


Disks 
These are available in both 3!⁄” and 51⁄4" format. Prices are as below: 


31/2 | £0.60 £5.00 

Disks come with labels (and protective covers for the 5 1/4" disks). Depend- 
ing on stocks available, bulk purchases may be possible. We cannot afford 
to carry a large stock ~ you figure what 1000 disks cost! Also, we can sell 


labels separately; we have one or two four colour rolls of 1000 each still left 
at £8 per roll. 


RAM Chips 
RAY chips suitable for the A590 hard drive, A2091 controller and many 
expansion boards are available for £22 per half meg (4 chips). These arè 


also suitable for the motherb 
oard of yer AS if y igs beso 
and knowledgeable! o the newer A500s, if you are very 
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Hardware 


Since CUGI has registered with Commodore (UK) as an Amiga Developer. 
we have been given access to very good discounts on their products. For 
what should be very obvious reasons, we cannot print a list of these nor will 


we give you a price list over the phone. If you wish to avail of this facility. 
please bear in mind that: 


e You must have been a member of CUGI for at least six months. 
e Only one system per member ~ no limits on smaller items, though. 


e The details of your purchase must be regarded as private — while Com- 
modore are quite happy to give us these discounts, it would take just 
one idiot to wander into his local computer shop, make some silly 
comment, and we will all lose. CUGI has signed an agreement with 


Commodore to respect the Amiga Developer Scheme - let’s not rock 
the boat. 


Finally, don’t forget that CUGI also offers a service for telephone leads and 


small repairs. Problems that cannot be fixed by the club can be passed on 
to a reliable and cheap repair person. 
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Flight Simulators 
by Rocco Matassa 


Let's talk about flight simulators. A computer like the Amiga should have 
no trouble running a halfway decent flight simulator. There are Several 
available: Falcon, Interceptor, Bomber, Flight Simulator II, F16 Combat 
Pilot, F19 Stealth Fighter and several others. There are also several on the 
horizon, including Mig 29, Light Aircraft Simulator, Flight of the Intruder, 
and F15 II. 

I am going to compare three of them - FS II, F19 and Falcon, the three 
that I consider the best. Before I examine these simulators though, let's 
look at what it is that makes them flight sims. 

The process by which a program is judged to be worthy of the term flight 
simulator begins when you first open the box it arrives in. Yes, even at this 
early stage, impressions are all important. This includes everything that 
comes with the package: the disk(s), the manual, the maps, the keyboard 
overlay, and instructions. 

This is the stage at which the potential of the program becomes appar- 
ent. The manual and instruction booklet (sometimes combined) are the 
most important. The manual must have been written clearly and with ex- 
amples. Those few pages have to inform you how to fly the plane, its uses 
(if military), and how to use any equipment provided. 

Flight sims are either military or civilian. FS II for exampleis civilian and 
therefore requires no background information on the area in which you will 
be flying, other than the location of airports, landing strips, navigational 
beacons and landmarks. Military flight sims do have goals other than flying, 
namely the death and destruction of your opponents. 

PS I has an excellent manual. It details all the controls and instruments 
of the aircraft and it manages to explain the basics of flight and instrument 

navigation. The manual for F19 is truly amazing. After reading the manual, 
you really feel as if you could step into an F117A and fiy it. The manual 
on P tobably the most difficult to get into and the hardest to a 
7i , $ gives the impression of an owners handbook (how many peop i 

you know who own a F16?) Of the three, the manual for F19 is the be 
aam a an important item. All the areas in F19 are detailed on ef 
Fl 3 ; con however has a much smaller area of operation than FSI 
FS tice maps, although the area is detailed in the man ; 

on top though; not only does it come with detailed 
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they are jampacked with information as well. But FS II goes one better: 
there are 12 scenery disks covering the US, Europe and Japan. These disks 
are interlinked and you can fly from one scenery area to another, even 
though they are on different disks. This one wins hands down for maps. 

Keyboard overlays or reference cards are another useful item, especially 
with complex simulators such as these three. Microprose supply an over- 
lay and a reference book detailing the controls, instruments and displays. 
SubLogic supply a reference card for FS II, which is useful but not as easy 
to use as the overlay. Falcon also comes with a reference card. 


The programs themselves are the last (but certainly not the least) thing 
to come under scrutiny. FS II is old, 1987 to be precise, and it shows. 
Compared to the others, it has the slowest screen update and consequently 
it appears jerky. The appearance of the cockpit instrumentation is fine but 
the cockpit views are a little awkward. This program is due for an update; 
the PC incarnation is up to revision four, and the improvements have been 
worthwhile. 

FS II was the first Amiga simulator to include provision for an analogue 
joystick, (in fact, this important feature was not included in any other 
simulator before F19). FS II also includes provision to link two computers 
together via a modem or null modem link. This is a fun way to learn to 
fly with another person, or to try and shoot each other out of the skies in 
a primitive war game. 

Falcon is the first of the modern sims to show how good and realistic 
things can be be made. Everything from the ground shading and cockpit 
views to the cockpit itself demonstrates this. It is not without a few faults 
though. Not all instrumentation is visible together; some requires switching 
to either a left or right view. It dearly needs an analogue joystick option, 
and landing is incredibly difficult. The program is popular enough to have 
spawned two mission disks, extending its life a bit. 

F19 has to be the best all rounder of the bunch however. It has a 
frame rate good enough not to distract you while flying, ground scenery 
in abundance, excellent instrumentation and displays, and hundreds if not 
thousands of missions to fly. 

These three sims represent the best available right now. Some like Falcon 
can be bought at discount prices from mail order companies for as little as 

. £12 and are great value. F19 sells for £20 (again I'm citing mail order 
prices). You may have some trouble tracking down FS II however, because 
of its age. Whichever one you opt for, all of these programs will provide 
you with hours of pleasure. Happy landings. 
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Amiga Graphics Programming 
by William Leeson 


The first thing you need to know when starting to program your Amiga 
for what it was intended (i.e. to stun) is to open a screen. So, how do 
you do this, I hear you ask. The first thing you have to do is to open the 
Intuition library so that you can access its functions. You could also open 
the screen another way using the lower level graphics functions but that is 
time consuming and not really of much benefit. 


To open the library, you call the OpenLibrary() function as follows: 


IntuitionBase = (struct IntuitionBase *) 
OpenLibrary("intuition.library", 0); - 


IntuitionBase is simply the structure that stores all the things going on 
while Intuition is being used. The 0 used at the end of the OpenLibrary/) 
call simply requests any version of intuition. library, which means that your 
program should work under any revision of the Amiga’s operating system. 
Now that you have opened the library, you can access the function you 
need to open a screen. Before calling this however, you need to setup a 
structure that contains information about what sort of screen you want: 


struct NewScreen 
{ 
SHORT LeftEdge, TopEdge, Width, Height, Depth; 
UBYTE DetailPen, BlockPen; 
USHORT ViewModes; 
USHORT Type; 
struct TextAttr *Font; 
UBYTE *DefaultTitle; 
struct Gadget *Gadgets; 


: struct BitMap *CustomBitMap ; 


Let's look at what the various fields in this structure mean. First i y 
need to specify the position of the screen. LeftEdge and Tori era f 
co-ordinates of the top left corner: LeftEdge is usually zero, ia ll 
can be set to start at any vertical ie i 
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The size of the screen is given by Width (usually 320 or 640, unless you’re 
using overscan) and Height. If you specify a Height of STDSCREENHEIGHT 
then your screen will be be the same height as the Workbench screen, which 
means that it will look okay on both NTSC and PAL Amigas. 


The Depth of the screen specifies how many bitplanes (from 1 to 6) to 
allocate. The more bitplanes you have, the more colours you can use (and 
the more memory your screen will require). Two bitplanes let you use four 
colours whereas five bitplanes give you 32 colours. 


DetailPen and BlockPen specify the colour to draw in and the colour 
to fill blocks with, respectively. These are used for things like the screen 
titlebar and the screen gadgets. 


ViewModes indicates what special hardware features your screen will 
use. There are quite a few possibilities. HIRES is the standard Amiga hires 
screen as seen on Workbench. LACE (interlace) gives you twice the vertical 
resolution, along with sore eyes and a headache. SPRITES allows you to 
use sprites with your screen. DUALPF (dual playfield) is handy for games, 
because it allows you to have two completely seperate screens; anything 
drawn in Colour 0 in the first screen allows whatever is behind on the 
second screen to show through. HAM gives you 4096 colours on the screen 
at one time, but is notoriously hard to program. You need to specify 6 
bitplanes for this mode to work. You can combine several screen modes 
(e.g. HIRES and INTERLACE) by ORing the appropriate flags, but you are 
not allowed to use HIRES with either DUALPF or HAM. 

Type gives the the sort of screen you want to use. It should almost always 
be set to CUSTOMSCREEN. You can set it to CUSTOMBITMAP instead if you 
want to use your own bitmap. Some additional values can also be specified. 
SCREENBEHIND opens your screen behind all the other screens (so that the 
user can’t see it until you've finished drawing into it for example), and 
SCREENQUIET stops Intuition from drawing a titlebar or gadgets in the 
screen at all. 

font points to an already initialised TextAttr structure. If you set this 
to NULL, you will get the default system font (which is normally Topaz 8). 
DefaultTitle points to a text string. This will be displayed in the titlebar 
of the screen if the titlebar is visible. 


Gadgets points to a list of gadgets if you want custom gadgets attached 


` to your screen. or else is just set to NULL. Finally, CustomBitmap points to 


a BitMap structure if you are doing special tricks. or just NULL if you want 
a standard bitmap. 
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s defined, you can use the function Open. 


Once your screen structure 1! 
Amiga: 


Screen() display your screen on the 
struct Screen *MyScreen, 
MyScreen = OpenScreen(&ScreenData) ; 

if (MyScreen == NULL) { 

/* Can’t open screen SO exit with error message */ 


} 


ScreenData is the screen structure you defined earlier. Don’t forget the 
preceding ampersand; this is because OpenScreen() expects a pointer to 
the structure rather than the structure itself. MyScreen is used to hold a 
pointer to the actual screen when it is opened; some of the other Intuition 
functions require you to pass this as a parameter (for example, if you want 
to open a window on your new screen). 

To finish off with, here’s a small complete example which opens a custom 
screen that you can slide up and down. To exit, type CTRL-C into the CLI 
window. Next time, I’ll look at how to actually DO something with the 
screen, once you’ve opened it. 


/* 
* Example of opening an Intuition Screen from C 


*/ 
#include <exec/types.h> 
#include <intuition/intuition.h> 


#include <libraries/dos.h> 


struct NewScreen ScreenData = 


{ 
0, /* LeftEdge K 
oe fe TopEdge Top of the display. xf 
Bt m Width We are using a lores screen * 
; , * Height Non-Interlaced Pal display ss 
0, /* Depth 8 colours (273 = 8) y 
z /* DetailPen Draw text in background col */ 
ae /* BlockPen Do fills in foreground col a 
CUSTOMSCREEN /* ViewModes Lores non-interlaced scree? y 
» /* Type A custom screen (of course) * 
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NULL, /* Font 


Default font is system font */ 


"My Screen", /* Title The screen title +/ 
NULL, /* Gadget No special gadgets */ 
NULL /* BitMap Just use a standard bitmap */ 
}; 
struct IntuitionBase *IntuitionBase; /* For Intuition */ 


struct Screen *MyScreen; /* 


/* 
* Start of program code 
*/ 
main() 
{ 
/* 


Ptr to our screen in memory */ 


* First of all, open the Intuition Library so 


* that we can use the 


*/ 


functions in it. 


IntuitionBase = (struct IntuitionBase *) 
OpenLibrary("intuition.library", 0); 


if (IntuitionBase == NULL 
exit(5); 

/* 

* Now open the screen 

*/ 


MyScreen = (struct Screen 


if (MyScreen == NULL) { 


) 


/* Can’t open Intuition */ 


*)OpenScreen(&ScreenData) ; 


/* Can’t open it */ 


CloseLibrary(IntuitionBase); /* Close Intuition */ 


exit (10); 
} 


Wait(SIGBREAKF_CTRL_C); 


CloseScreen(MyScreen) ; 


/* Wait for CTRL-C */ 


/* Close screen */ 


CloseLibrary(IntuitionBase) ; /* Close Intuition */ 
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A Tourist’s Guide to JR-Comm 
by Declan McArdle 


Introduction a 
JR-Comm was first introduced to an unsuspecting public in 1988 ang sti 


then it has established itself as the premier Amiga telecommunications pack. 
age. The program has been constantly updated, with more and more fea- 
tures being crammed into each update. Currently it sports over half a dozen 
file transfer protocols, and terminal emulations ranging from Amiga ANS] 
to VT-100 to IBM Colour ANSI to ordinary TTY. 


The current version of JR-Comm is V1.01; this fixes a couple of bugs 
which made it incompatible with Workbench 2.0. This article is intended 
to help you get the most out of using JR-Comm. It is not a quick installation 
guide; it’s a guide to JR-Comm’s myriad features. 


File Transfers 

JR-Comm has nine (count ’em!) file transfer protocols, ranging from the 
antiquated XMODEM? to YMODEM to Chuck Forsberg’s excellent ZMODEM. 
JR-Comm also caters for users of error-correcting modems such as those 
that offer MNP? level 4 error correction and/or V42 LAPM* by having 
YMODEM-G, a variant on YMODEM which does no error checking itself (be- 
cause the modem is doing the error-correcting at the hardware level). This 
can improve the throughput to 99% of the theoretical maximum. 


In general though, ZMODEM is the best because it is a batch protocol and 
therefore transmits details such as the filename and file size at the beginning 
of the transfer. JR-Comm estimates the time it will take to download the 
file initially and adjusts it dynamically as the transfer progresses; upwards 
in the case of a poor line and downwards in the case of a clear line with no 
noise. This is handy if you're downloading a large file and wish to 6° off 
and make a cup of tea or some such as you'll know when to come back :- 

Another nice option is AUTO DOWNLOAD which, when enabled, allows 
JR-Comm to detect when the remote computer is sending you a ZMODEM file 
and automatically start downloading it, all without you having t° do any- 
thing. Alongside this is is RESUME TRANSFER which will resume 4 transfer 


Often referred 5 
to y 
as Christensen protocol after its inventor Ward Christensen i protocol that 


MNP is an anacron : 
. ym A S Š 
can be implemented in a esau Networking Protocol, a software-based link connec 


2, 
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‘Link 
ink Access Protocol for Modems, the CCITTs equivalent of MNP 
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which was previously aborted for some reason (assuming the BBS program 
dosen't send out a ZMCLOB like certain packages!) 


Dialing Directory 

This is usually the feature which either makes or breaks a telecommunica- 
tions package. In JR-Comm’s case, it makes it. With the dialing directory, 
it is possible to completely reconfigure your whole communications environ- 
ment for each phone number. The number of phone numbers available is 
limited only by memory. The following options are available: 


Dial Dial the selected entries 

Edit Edit an entry in the directory 

Unselect Unselect selected entries (entries you clicked on) 
Delete Delete a selected entry from the directory 


Add Add an entry to the directory 

Sort Sort the entries (by name, number or selectively) 
Load Load a different phonebook 

Save Save this phonebook 


JR-Comm can detect whether a dialled entry is engaged, ringing or if it was 
answered by a human. In the modem setup, there are settings to indicate 
how long the modem should wait for a carrier before giving up. Using tone 
dialing, 30 seconds should do, 45 for pulse dialing. Also included is the 
number of times to redial engaged numbers (999 will virtually guarantee 
that you get through eventually) and the duration to wait before redialing. 

If you have the advantage of having lots of systems to call, JR-Comm has 
the ability to generate a unique password for each entry in the directory. 
This password can then be sent after you enter your name on the remote 
system. 


Serial & Modem Configuration 
JR-Comm can address the serial port at speeds of up to 57,600 bits per 
second. For use with an error-correcting modem, a rate of 19,200 or 38,400 
bps is most effective. JR-Comm supports all the usual word configuration 
options: 7 or 8 bit length words; parity set to even, odd, mark, space or 
none; 1 or 2 stop bits. For modems which require flow control (typically 
error-correcting modems), you have a choice of either XON/XOFF (software 
‘ handshaking) or CTS/RTS (hardware handshaking). 

In the modem setup requester, you can configure the redial options, the 
dial prefixes (whether a dial command is ATDP for pulse, ATDT for tone, 
or another AT command which. for example, turns on MNP), or enter the 


January 1991 19 


are also some handy options, such as Ignore No 


initialisation string. There 
ful for people using modems that don’t set the 


Carrier, which might be use 
DCD (Carrier Detect) pin 


Terminal Emulation 
JR-Comm’s seven Terminal Emulations are: TTY, Amiga, IBM Colour, 


IBM Mono, VT-100, VT-102, and SkyPix. The first four are common 
enough on Bulletin Boards; a lot of boards around nowadays will have IBM 
graphics characters in their menus, and JR-Comm supports these fully. The 
VT-100 and VT-102 are emulations of terminals that you would normally 
find hooked up to mainframes and the like. So, using JR-Comm you can 
now connect to your College/place of work, and use the mainframe in the 
same way you normally would if you were there. 

SkyPix is a new system which is mainly used in the States. I’m not too 
familiar with it but I think the general idea is that you pre-download all the 
menus to your system, and then the SkyPix host just sends you the mini- 
mum information needed. If anyone has some more information could they 
please contact me at 2:253/198 on Fidonet, at dmcardle@dbug . hobby. ie, 
or care of CUGI. 


Miscellaneous 
That concludes the guided tour of JR-Comm, except to say that there are 
a few more things that JR-Comm has which I didn’t mention. These are: 


Chat Line Allows you to type in and edit text on the bottom line 
of the screen which only gets transmitted after you press 
RETURN. 

Clock Displays both current and online time (12 or 24 hour 
format). 


Review Buffer Lets you scroll back over text that you previously read. 


Disk Check Checks your disk to see if the file you're trying to down- 
load will fit. 


M : 
eis Up to 40 different macro key bindings are available, 10 
each for the qualifiers Normal, Control, Shift and Alt. 


Print i at! at 
er Options Print either the screen display or all transmitted text. 
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